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Abstract 

We describe a derivational approach to abstract interpretation that 
yields novel and transparently sound static analyses when applied 
to well-established abstract machines. To demonstrate the tech- 
nique and support our claim, we transform the CEK machine 
of Felleisen and Friedman, a lazy variant of Rrivine's machine, 
and the stack-inspecting CM machine of Clements and Felleisen 
into abstract interpretations of themselves. The resulting analyses 
bound temporal ordering of program events; predict return-flow 
and stack-inspection behavior; and approximate the flow and eval- 
uation of by-need parameters. For all of these machines, we find 
that a series of well-known concrete machine refactorings, plus a 
technique we call store-allocated continuations, leads to machines 
that abstract into static analyses simply by bounding their stores. 
We demonstrate that the technique scales up uniformly to allow 
static analysis of realistic language features, including tail calls, 
conditionals, side effects, exceptions, first-class continuations, and 
even garbage collection. 

Categories and Subject Descriptors F.3.2 [Logics and Meanings 
of Programs]: Semantics of Programming Languages — Program 
analysis, Operational semantics; F.4.1 [Mathematical Logic and 
Formal Languages]: Mathematical Logic — Lambda calculus and 
related systems 

General Terms Languages, Theory 

Keywords abstract machines, abstract interpretation 

1. Introduction 

Abstract machines such as the CEK machine and Rrivine's ma- 
chine are first-order state transition systems that represent the core 
of a real language implementation. Semantics-based program anal- 
ysis, on the other hand, is concerned with safely approximating 
intensional properties of such a machine as it runs a program. It 
seems natural then to want to systematically derive analyses from 
machines to approximate the core of realistic run-time systems. 

Our goal is to develop a technique that enables direct abstract 
interpretations of abstract machines by methods for transforming 
a given machine description into another that computes its finite 
approximation. 
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We demonstrate that the technique of refactoring a machine 
with store-allocated continuations allows a direct structural ab- 
stractiory by bounding the machine's store. Thus, we are able to 
convert semantic techniques used to model language features into 
static analysis techniques for reasoning about the behavior of those 
very same features. By abstracting well-known machines, our tech- 
nique delivers static analyzers that can reason about by-need evalu- 
ation, higher-order functions, tail calls, side effects, stack structure, 
exceptions and first-class continuations. 

The basic idea behind store-allocated continuations is not new. 
SML/NJ has allocated continuations in the heap for well over a 
decade [28|. At first glance, modeling the program stack in an ab- 
stract machine with store-allocated continuations would not seem 
to provide any real benefit. Indeed, for the purpose of defining the 
meaning of a program, there is no benefit, because the meaning 
of the program does not depend on the stack-implementation strat- 
egy. Yet, a closer inspection finds that store-allocating continua- 
tions eliminate recursion from the definition of the state-space of 
the machine. With no recursive structure in the state-space, an ab- 
stract machine becomes eligible for conversion into an abstract in- 
terpreter through a simple structural abstraction. 

To demonstrate the applicability of the approach, we derive 
abstract interpreters of: 

• a call-by- value A-calculus with state and control based on the 
CESK machine of Felleisen and Friedman 1 13 1, 

• a call-by-need A-calculus based on a tail-recursive, lazy vari- 
ant of Krivine's machine derived by Ager, Danvy and Midt- 
gaard (Tj, and 

• a call-by-value A-calculus with stack inspection based on the 
CM machine of Clements and Felleisen (3); 

and use abstract garbage collection to improve precision |25|. 

Overview 

In Section[2] we begin with the CEK machine and attempt a struc- 
tural abstract interpretation, but find ourselves blocked by two re- 
cursive structures in the machine: environments and continuations. 
We make three refactorings to: 

1. store-allocate bindings, 

2. store-allocate continuations, and 

3. time-stamp machine states; 

resulting in the CESK, CESK*, and time-stamped CESK* ma- 
chines, respectively. The time-stamps encode the history (context) 
of the machine's execution and facilitate context-sensitive abstrac- 
tions. We then demonstrate that the time-stamped machine ab- 
stracts directly into a parameterized, sound and computable static 
analysis. 



A structural abstraction distributes component-, point-, and member-wise. 



In Section[3] we replay this process (slightly abbreviated) with 
a lazy variant of Krivine's machine to arrive at a static analysis of 
by-need programs. 

In Section [4] we incorporate conditionals, side effects, excep- 
tions, first-class continuations, and garbage collection. 

In Section[6] we abstract the CM (continuation-marks) machine 
to produce an abstract interpretation of stack inspection. 

In Section[7] we widen the abstract interpretations with a single- 
threaded "global" store to accelerate convergence. For some of our 
analyzers, this widening results in polynomial-time algorithms and 
connects them back to known analyses. 

2. From CEK to the abstract CESK* 

In this section, we start with a traditional machine for a program- 
ming language based on the call-by-value A-calculus, and gradu- 
ally derive an abstract interpretation of this machine. The outline 
followed in this section covers the basic steps for systematically 
deriving abstract interpreters that we follow throughout the rest of 
the paper. 

To begin, consider the following language of expressions^ 

e G Exp ::— x (ee) j (~hx.e) 
x G Var a set of identifiers. 

A standard machine for evaluating this language is the CEK ma- 
chine of Felleisen and Friedman 1 12 1, and it is from this machine 
we derive the abstract semantics — a computable approximation of 
the machine's behavior. Most of the steps in this derivation corre- 
spond to well-known machine transformations and real-world im- 
plementation techniques — and most of these steps are concerned 
only with the concrete machine; a very simple abstraction is em- 
ployed only at the very end. 

The remainder of this section is outlined as follows: we present 
the CEK machine, to which we add a store, and use it to allo- 
cate variable bindings. This machine is just the CESK machine of 
Felleisen and Friedman [ 13 1. From here, we further exploit the store 
to allocate continuations, which corresponds to a well-known im- 
plementation technique used in functional language compilers [ 28 ] . 
We then abstract only the store to obtain a framework for the sound, 
computable analysis of programs. 

2.1 The CEK machine 

A standard approach to evaluating programs is to rely on a Curry- 
Feys-style Standardization Theorem, which says roughly: if an 
expression e reduces to e' in, e.g., the call-by-value A-calculus, 
then e reduces to e' in a canonical manner. This canonical manner 
thus determines a state machine for evaluating programs: a standard 
reduction machine. 

To define such a machine for our language, we define a grammar 
of evaluation contexts and notions of reduction (e.g., /3 V ). An eval- 
uation context is an expression with a "hole" in it. For left-to-right 
evaluation order, we define evaluation contexts E as: 

E::=[]\ {Ee) \ (vE). 



>CEK ? 



2 Fine print on syntax: As is often the case in program analysis where se- 
mantic values are approximated using syntactic phrases of the program un- 
der analysis, we would like to be able to distinguish different syntactic oc- 
currences of otherwise identical expressions within a program. Informally, 
this means we want to track the source location of expressions. Formally, 
this is achieved by labeling expressions and assuming all labels within a 
program are distinct: 

e G Exp ::= x e | (ee) | (\x.e~) 
£ G Lab an infinite set of labels. 

However, we judiciously omit labels whenever they are irrelevant and doing 
so improves the clarity of the presentation. Consequently, they appear only 
in Sections l2.7l andP71 which are concerned with fe-CFA. 



{x,p,n) 


(v, p' , n) where p(x) = (v, p') 


((e ei),p, k) 


(e ,p,ar(e 1 ,p,K)} 


(v,p,ar(e,p',K)) 


(e,p',fn(v,p,K)) 


(v,p, fn((Ax.e),p',ti)) 


(e,p'[x^ {v,p)],K) 



Figure 1. The CEK machine. 



An expression is either a value or uniquely decomposable into an 
evaluation context and redex. The standard reduction machine is: 

E[e] i — >p, E[e'], ife /W. 

However, this machine does not shed much light on a realistic 
implementation. At each step, the machine traverses the entire 
source of the program looking for a redex. When found, the redex 
is reduced and the contractum is plugged back in the hole, then the 
process is repeated. 

Abstract machines such as the CEK machine, which are deriv- 
able from standard reduction machines, offer an extensionally 
equivalent but more realistic model of evaluation that is amenable 
to efficient implementation. The CEK is environment-based; it uses 
environments and closures to model substitution. It represents eval- 
uation contexts as continuations, an inductive data structure that 
models contexts in an inside-out manner. The key idea of machines 
such as the CEK is that the whole program need not be traversed 
to find the next redex, consequently the machine integrates the pro- 
cess of plugging a contractum into a context and finding the next 
redex. 

States of the CEK machine 1121 consist of a control string (an 
expression), an environment that closes the control string, and a 
continuation: 

C£S = Exp x Env x Kont 

v G Vol ::— (Ax.e) 

p G Env — Var — >fi n Vol x Env 

K G Kont ::= mt | ar(e,p, «) | fn(v,p, k). 

States are identified up to consistent renaming of bound variables. 

Environments are finite maps from variables to closures. Envi- 
ronment extension is written p[x h* (v, p')]. 

Evaluation contexts E are represented (inside-out) by continua- 
tions as follows: [ ] is represented by mt; E[(.[ ]e)] is represented 
by ar(e', p, k) where p closes e' to represent e and k represents 
E; E\{v\ ])] is represented by fn(v',p, k) where p closes v' to 
represent v and k represents E. 

The transition function for the CEK machine is defined in Fig- 
ure Q] (we follow the textbook treatment of the CEK machine 1111 
page 102]). The initial machine state for a closed expression e is 
given by the inj function: 

m 3cEK( e ) = <e,0,mt). 

Typically, an evaluation function is defined as a partial function 
from closed expressions to answers: 

eval' CEK (e) = (v,p) if inj(e) < — » C ek (v,p,mt). 

This gives an extensional view of the machine, which is useful, e.g., 
to prove correctness with respect to a canonical evaluation function 
such as one defined by standard reduction or compositional valu- 
ation. However for the purposes of program analysis, we are con- 
cerned more with the intensional aspects of the machine. As such, 
we define the meaning of a program as the (possibly infinite) set of 
reachable machine states: 

evalcEK{e) = {? | inj(e) i — »cek ?}• 



Deciding membership in the set of reachable machine states 
is not possible due to the halting problem. The goal of abstract 
interpretation, then, is to construct a function, aval-^r^, that is a 
sound and computable approximation to the evalcEK function. 

We can do this by constructing a machine that is similar in struc- 
ture to the CEK machine: it is defined by an abstract state transition 
relation (i — >rfgg) G E x E, which operates over abstract states, 
E, which approximate the states of the CEK machine, and an ab- 
straction map a : E — > E that maps concrete machine states into 
abstract machine states. 

The abstract evaluation function is then defined as: 

"fefe) = {? I o.{inj{e)) i — »p^ ?}. 

1. We achieve decidability by constructing the approximation in 
such a way that the state-space of the abstracted machine is 
finite, which guarantees that for any closed expression e, the 
set aval(e) is finite. 

2. We achieve soundness by demonstrating the abstracted ma- 
chine transitions preserve the abstraction map, so that if c i — > 
<;' and a(<;) C <;, then there exists an abstract state <;' such that 
C i— >■ ? and a(V) E <?'• 



A first attempt at abstract interpretation: A simple approach 
to abstracting the machine's state space is to apply a structural 
abstract interpretation, which lifts abstraction point-wise, element- 
wise, component-wise and member-wise across the structure of a 
machine state (i.e., expressions, environments, and continuations). 

The problem with the structural abstraction approach for the 
CEK machine is that both environments and continuations are 
recursive structures. As a result, the map a yields objects in an 
abstract state-space with recursive structure, implying the space 
is infinite. It is possible to perform abstract interpretation over an 
infinite state-space, but it requires a widening operator. A widening 
operator accelerates the ascent up the lattice of approximation and 
must guarantee convergence. It is difficult to imagine a widening 
operator, other than the one that jumps immediately to the top of 
the lattice, for these semantics. 

Focusing on recursive structure as the source of the problem, a 
reasonable course of action is to add a level of indirection to the 
recursion — to force recursive structure to pass through explicitly 
allocated addresses. In doing so, we will unhinge recursion in 
a program's data structures and its control-flow from recursive 
structure in the state-space. 

We turn our attention next to the CESK machine [10. 13), since 
the CESK machine eliminates recursion from one of the structures 
in the CEK machine: environments. In the subsequent section (Sec- 
tion [23}, we will develop a CESK machine with a pointer refine- 
ment (CESK*) that eliminates the other source of recursive struc- 
ture: continuations. At that point, the machine structurally abstracts 
via a single point of approximation: the store. 

2.2 The CESK machine 

The states of the CESK machine extend those of the CEK machine 
to include a store, which provides a level of indirection for variable 
bindings to pass through. The store is a finite map from addresses 
to storable values and environments are changed to map variables 
to addresses. When a variable's value is looked-up by the machine, 
it is now accomplished by using the environment to look up the 
variable's address, which is then used to look up the value. To 
bind a variable to a value, a fresh location in the store is allocated 
and mapped to the value; the environment is extended to map the 
variable to that address. 
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>CESK ? 


(x,p,cr,K) 




(v, p , a, k) where a(p(x)) = (v, p') 


((e ei),p, a, k) 




{e Q ,p,a, ar(ei,p, «)) 


(v,p,a,ar(e,p',K)) 




(e, p', cr, tn(v, p, «)) 


(v,p, a, fn((Aa;.e),p' 


«)> 


(e, p'[x h-> a], cr[a H- (v, p)], k) 
where a £ dom(a) 



Figure 2. The CESK machine. 



The state space for the CESK machine is defined as follows: 

? G E = Exp x Env x Store x Kont 

p G Env = Var — >fl n Addr 

a G Store = Addr — >fl n Storable 
s € Storable = Vol x Env 
a,b,c £ Addr an infinite set. 

States are identified up to consistent renaming of bound variables 
and addresses. The transition function for the CESK machine is 
defined in Figure[2](we follow the textbook treatment of the CESK 
machine |11 page 166]). 

The initial state for a closed expression is given by the inj func- 
tion, which combines the expression with the empty environment, 
store, and continuation: 



inJcEsAe) = ( e > 



, mt>. 



The evalcESK evaluation function is defined following the tem- 
plate of the CEK evaluation given in Section l2~T1 

evalcESK(e) - {<; | wy'(e) i — »cesk ?}• 

Observe that for any closed expression, the CEK and CESK ma- 
chines operate in lock-step: each machine transitions, by the corre- 
sponding rule, if and only if the other machine transitions. 



Lemma 1 (Felleisen, 1101 ). evalcESx(e) 



evalc 



f(e). 



A second attempt at abstract interpretation: With the CESK ma- 
chine, half the problem with the attempted naive abstract interpre- 
tation is solved: environments and closures are no longer mutually 
recursive. Unfortunately, continuations still have recursive struc- 
ture. We could crudely abstract a continuation into a set of frames, 
losing all sense of order, but this would lead to a static analysis lack- 
ing faculties to reason about return-flow: every call would appear 
to return to every other call. A better solution is to refactor contin- 
uations as we did environments, redirecting the recursive structure 
through the store. In the next section, we explore a CESK machine 
with a pointer refinement for continuations. 

2.3 The CESK* machine 

To untie the recursive structure associated with continuations, we 
shift to store-allocated continuations. The Kont component of the 
machine is replaced by a pointer to a continuation allocated in 
the store. We term the resulting machine the CESK* (control, 
environment, store, continuation pointer) machine. Notice the store 
now maps to denotable values and continuations: 

c 6 E = Exp x Env x Store x Addr 

s G Storable — Val x Env + Kont 

K G Kont ::= mt | ar(e,p, a) | fn(v,p, a). 

The revised machine is defined in Figure [3] and the initial ma- 
chine state is defined as: 

in JcESK*( e ) = ( e >®> [O0 ^ Hit], Co). 



C i — >cesk* ?', where k — a(a),b £ dom(o) 


(x,p,o,a) 


(v, p', cr, a) where (u, p') = a(p(x)) 


((e ei),/9, cr, a) 


(e ,p,a[b^ ar(ei,p,o)],6) 


(v,p,a,a) 

if re = ar(e, p',c) 

if k — fn((Aa;.e) , p' , c) 


(e,p',cr[bi->fn(t;,p,c)],c.) 
{e,p'[x M> 6],<j[&h. (v,p)],c) 



? ' >CESK* C , 


where 


ft 


= cr(a), b = alloc(<;),u = tick(<;) 


(x,p,o,a,t) 






(V 


p' , a, a, u) where (v, p') = a(p(x)) 


(Ce ei),p,a,a,t) 








(e ,p, a[b h-> ar(ei,p, a)],6, m) 


(v,p,o,a,t) 










if ft = ar(e, p, c) 








(e, p, a[b !-»■ fn(t),p,c)],6,«) 


if ft = fn((A:r.e), 


t 

P 


c) 




(e, p'[x M> 6], cr[6 M- (u, p)], c, u) 



Figure 3. The CESK* machine. 



Figure 4. The time-stamped CESK* machine. 



The evaluation function (not shown) is defined along the same 
lines as those for the CEK (Section [2. It and CESK (Section [2. 2t 
machines. Like the CESK machine, it is easy to relate the CESK* 
machine to its predecessor; from corresponding initial configura- 
tions, these machines operate in lock-step: 

Lemma 2. evalcESK*(e) ~ evalcESK(e). 

Addresses, abstraction and allocation: The CESK* machine, as 
defined in Figure [3] nondeterministically chooses addresses when 
it allocates a location in the store, but because machines are iden- 
tified up to consistent renaming of addresses, the transition system 
remains deterministic. 

Looking ahead, an easy way to bound the state-space of this 
machine is to bound the set of addresses[j But once the store is 
finite, locations may need to be reused and when multiple values 
are to reside in the same location; the store will have to soundly 
approximate this by joining the values. 

In our concrete machine, all that matters about an allocation 
strategy is that it picks an unused address. In the abstracted ma- 
chine however, the strategy may have to re-use previously allo- 
cated addresses. The abstract allocation strategy is therefore cru- 
cial to the design of the analysis — it indicates when finite resources 
should be doled out and decides when information should deliber- 
ately be lost in the service of computing within bounded resources. 
In essence, the allocation strategy is the heart of an analysis (allo- 
cation strategies corresponding to well-known analyses are given 
in Section l277l ) 

For this reason, concrete allocation deserves a bit more atten- 
tion in the machine. An old idea in program analysis is that dy- 
namically allocated storage can be represented by the state of the 
computation at allocation time 1 18. 22, Section 1.2.2]. That is, allo- 
cation strategies can be based on a (representation) of the machine 
history. These representations are often called time-stamps. 

A common choice for a time-stamp, popularized by Shiv- 
ers 1291 . is to represent the history of the computation as contours, 
finite strings encoding the calling context. We present a concrete 
machine that uses general time-stamp approach and is parameter- 
ized by a choice of tick and alloc functions. We then instantiate 
tick and alloc to obtain an abstract machine for computing a k- 
CFA-style analysis using the contour approach. 

2.4 The time-stamped CESK* machine 

The machine states of the time-stamped CESK* machine include a 
time component, which is intentionally left unspecified: 

t, u € Time 

<; € E = Exp x Env x Store x Addr x Time. 

The machine is parameterized by the functions: 

tick : E — s> Time alloc : E — ► Addr. 



The tick function returns the next time; the alloc function allocates 
a fresh address for a binding or continuation. We require of tick 
and alloc that for all t and c, t \Z tick(<;) and allocfc) <£ o where 

C = (-,-,<?, -,-}• 

The time-stamped CESK* machine is defined in Figure|4] Note 
that occurrences of <j on the right-hand side of this definition are 
implicitly bound to the state occurring on the left-hand side. The 
initial machine state is defined as: 

ity cesk? (e) = (e,0, [o ^ mt],o ,*o). 

Satisfying definitions for the parameters are: 

Time = Addr = Z 
ao — to = tick{-, -,-,-, t) — t+ 1 alloc{_, _, _, _, t) — t. 



3 A finite number of addresses leads to a finite number of environments, 
which leads to a finite number of closures and continuations, which in turn, 
leads to a finite number of stores, and finally, a finite number of states. 



Under these definitions, the time-stamped CESK* machine oper- 
ates in lock-step with the CESK* machine, and therefore with the 
CESK and CEK machines as well. 

Lemma 3. evalcESK?(e) — evalcESK*{e). 

The time-stamped CESK* machine forms the basis of our ab- 
stracted machine in the following section. 

2.5 The abstract time-stamped CESK* machine 

As alluded to earlier, with the time-stamped CESK* machine, we 
now have a machine ready for direct abstract interpretation via a 
single point of approximation: the store. Our goal is a machine 
that resembles the time-stamped CESK* machine, but operates 
over a finite state-space and it is allowed to be nondeterministic. 
Once the state-space is finite, the transitive closure of the transition 
relation becomes computable, and this transitive closure constitutes 
a static analysis. Buried in a path through the transitive closure 
is a (possibly infinite) traversal that corresponds to the concrete 
execution of the program. 

The abstracted variant of the time-stamped CESK* machine 
comes from bounding the address space of the store and the number 
of times available. By bounding these sets, the state-space becomes 
finite(jbut for the purposes of soundness, an entry in the store may 
be forced to hold several values simultaneously: 

a £ Store = Addr — »fi n V (Storable). 

Hence, stores now map an address to a set of storable values rather 
than a single value. These collections of values model approxima- 
tion in the analysis. If a location in the store is re-used, the new 
value is joined with the current set of values. When a location is 
dereferenced, the analysis must consider any of the values in the 
set as a result of the dereference. 

The abstract time-stamped CESK* machine is defined in Fig- 
ure [5] The (non-deterministic) abstract transition relation changes 
little compared with the concrete machine. We only have to modify 
it to account for the possibility that multiple storable values (which 



4 Syntactic sets like Exp are infinite, but finite for any given program. 



*•— »C8gifj ?', where ft 


G o(a),b — alloc(q, k), U — tick(q, k) 


{x,p,a,a,t) 


(«, p' , a, a, u) where (v, p') G a(p(x)) 


{(e ei),p, <r,a,t) 


(eo,p,a U [b i-J- ar(ei, p, a)], fa, it) 


{v,p,a,a,t) 




if ft = ar(e, p',c) 


(e, p', itU[6i-> fn(?;, p, c)], 6, u) 


if K = fn((A:r.e) , p' ,c) 


(e, p'[x h-> 6] , a U [6 !->■ (w, /»)], c, w) 



Figure 5. The abstract time-stamped CESK* machine. 



includes continuations) may reside together in the store, which we 
handle by letting the machine non-deterministically choose a par- 
ticular value from the set at a given store location. 

The analysis is parameterized by abstract variants of the func- 
tions that parameterized the concrete version: 

tick : E x Kont — > Time, alloc : £ x Kont — > Addr. 

In the concrete, these parameters determine allocation and stack 
behavior. In the abstract, they are the arbiters of precision: they 
determine when an address gets re-allocated, how many addresses 
get allocated, and which values have to share addresses. 

Recall that in the concrete semantics, these functions consume 
states — not states and continuations as they do here. This is because 
in the concrete, a state alone suffices since the state determines the 
continuation. But in the abstract, a continuation pointer within a 
state may denote a multitude of continuations; however the tran- 
sition relation is defined with respect to the choice of a particular 
one. We thus pair states with continuations to encode the choice. 

The abstract semantics computes the set of reachable states: 

aval , 



;*( e ) = {■? I (e,0, [oo i->- mt],oo, 



to) 



c}. 



2.6 Soundness and computability 

The finiteness of the abstract state-space ensures decidability. 

Theorem 1 (Decidability of the Abstract CESK* Machine). 
C G aval pSSx?* (e) is decidable. 

Proof. The state-space of the machine is non-recursive with finite 
sets at the leaves on the assumption that addresses are finite. Hence 
reachability is decidable since the abstract state-space is finite. □ 

We have endeavored to evolve the abstract machine gradually so 
that its fidelity in soundly simulating the original CEK machine is 
both intuitive and obvious. But to formally establish soundness of 
the abstract time-stamped CESK* machine, we use an abstraction 
function, defined in Figure [6] from the state-space of the concrete 
time-stamped machine into the abstracted state-space. 

The abstraction map over times and addresses is defined so 
that the parameters alloc and tick are sound simulations of the 
parameters alloc and tick, respectively. We also define the partial 
order (C) on the abstract state-space as the natural point- wise, 
element-wise, component- wise and member-wise lifting, wherein 
the partial orders on the sets Exp and Addr are flat. Then, we 
can prove that abstract machine's transition relation simulates the 
concrete machine's transition relation. 

Theorem 2 (Soundness of the Abstract CESK* Machine). 

If c, i — >cek ? and a(c) E £ then there exists an abstract state 



? , such that <f i 



CESK t 



C and a(<; ) C <f , 



a(e, p, a, a, t) = (e, a(p), a(o), a(a),a(t)) [states] 

a(p) = \x.a(p(x)) [environments] 

n[rr) - \a. I I \<\(o~(a))\ [stores] 



4a) = AS. [J (a((r(o))} 

a((\x.e),p) = ((Ax.e),a(p)) 

a(mt) = mt 
a(ar(e,/9,a)) = ar(e, a(p), a(o)) 

a(fn(v, p, a)) = fn(v, a(p), a(a)), 



[closures] 
[continuations] 



Proof. By Lemmas[T][2] and[3] it suffices to prove soundness with 
respect to i — >cesk*- Assume q i — >cesk* ?' and a(q) C t 



Figure 6. The abstraction map, a : T,cesk* — ► E^-p7rp* 



Because c, transitioned, exactly one of the rules from the definition 
of (i — >cesk*) applies. We split by cases on these rules. The rule 
for the second case is deterministic and follows by calculation. 
For the the remaining (nondeterministic) cases, we must show 
an abstract state exists such that the simulation is preserved. By 
examining the rules for these cases, we see that all three hinge on 
the abstract store in c soundly approximating the concrete store in 
<;, which follows from the assumption that a(?) C q. □ 

2.7 A fe-CFA-like abstract CESK* machine 

In this section, we instantiate the time-stamped CESK* machine 
to obtain a contour-based machine; this instantiation forms the 
basis of a context-sensitive abstract interpreter with polyvariance 
like that found in fc-CFA |29|. In preparation for abstraction, we 
instantiate the time-stamped machine using labeled call strings. 

Inside times, we use contours (Contour), which are finite 
strings of call site labels that describe the current context: 

S G Contour ::— e | 18. 

The labeled CESK machine transition relation must appropri- 
ately instantiate the parameters tick and alloc to augment the time- 
stamp on function call. 

Next, we switch to abstract stores and bound the address space 
by truncating call string contours to length at most k (for fc-CFA): 

S G Contour k iff S G Contour and \8\ < fc. 

Combining these changes, we arrive at the instantiations for the 
concrete and abstract machines given in Figure [7] where the value 
[<5J k is the leftmost fc labels of contour 8. 

Comparison to k-CFA: We say "fc-CFA-like" rather than "fc- 
CFA" because there are distinctions between the machine just de- 
scribed and fc-CFA: 

1. fc-CFA focuses on "what flows where"; the ordering between 
states in the abstract transition graph produced by our machine 
produces "what flows where and when." 

2. Standard presentations of fc-CFA implicitly inline a global ap- 
proximation of the store into the algorithm 1 29 1 ; ours uses one 
store per state to increase precision at the cost of complexity. In 
terms of our framework, the lattice through which classical fc- 
CFA ascends is V (Exp x Env x Addr) x Store, whereas our 
analysis ascends the lattice V ( Exp x Env x Store x Addr ) . 

We can explicitly inline the store to achieve the same complex- 
ity, as shown in Section|7] 

3. On function call, fc-CFA merges argument values together with 
previous instances of those arguments from the same context; 
our "minimalist" evolution of the abstract machine takes a 



tick{v, _, a, a, (£, 8)) — 



Time = (Lab + •) x Contour 
Addr = (Lab + Var) x Contour 

to = (»,e) 
tick(x, _, _, _, t) = t 

tick((.e e 1 ) e , _,_,_, (-,5)) = (£,5) 

'(£,5), if(T(o)=BP(___) 

_(•,£<*), ifa(a) = fn(.,.,_) 

oiioc(((eoei), _,_,_,(_, 5))) = (1,5) 

alloc({v,-,a, a, (_, 5))) — (1,5) if cr(o) = ar(e , _, _) 
alloc({v,-,a, a, (_, 5))) = (x,5) if cr(a) = fn((Ai.e), _, _) 

tick((x, _, _, _,£}, «) = i 
iicA:(((eoei) ,_,_,_, (_, £)),«;) = (^,<5) 

tick((v,.,o,a,(l,5)),K)= \) ' ) 

{(•,llS\ k ), if k = fn(_, ., _) 

alhc(((e i ei\ -,-,-,(-, 5)), k) = (/,*) 

alloc({v, _, it, a, (_, (5)), k) = (•£, <5) if « = ar(e f ,_, _) 

alloc((v, _, a, a, (_, 5)), k) = (a;, <5) if k = fn((Aa;.e) , _, _) 
Figure 7. Instantiation for fc-CFA machine. 



higher-precision approach: it forks the machine for each ar- 
gument value, rather than merging them immediately. 

4. fc-CFA does not recover explicit information about stack struc- 
ture; our machine contains an explicit model of the stack for 
every machine state. 

3. Analyzing by-need with Krivine's machine 

Even though the abstract machines of the prior section have advan- 
tages over traditional CFAs, the approach we took (store-allocated 
continuations) yields more novel results when applied in a different 
context: a lazy variant of Krivine's machine. That is, we can con- 
struct an abstract interpreter that both analyzes and exploits lazi- 
ness. Specifically, we present an abstract analog to a lazy and prop- 
erly tail-recursive variant of Krivine's machine 1 19, 20] derived by 
Ager, Danvy, and Midtgaard 1 1], The derivation from Ager et al.'s 
machine to the abstract interpreter follows the same outline as that 
of Section[2] we apply a pointer refinement by store-allocating con- 
tinuations and carry out approximation by bounding the store. 

The by-need variant of Krivine's machine considered here uses 
the common implementation technique of store-allocating thunks 
and forced values. When an application is evaluated, a thunk is 
created that will compute the value of the argument when forced. 
When a variable occurrence is evaluated, if it is bound to a thunk, 
the thunk is forced (evaluated) and the store is updated to the result. 
Otherwise if a variable occurrence is evaluated and bound to a 
forced value, that value is returned. 

Storable values include delayed computations (thunks) d(e, p), 
and computed values c(v, p), which are just tagged closures. There 
are two continuation constructors: ci (o, k) is induced by a variable 
occurrence whose binding has not yet been forced to a value. 
The address a is where we want to write the given value when 
this continuation is invoked. The other: C2 (o, k) is induced by an 
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1 >LK ? 


(x,p,cr,K) 
ifa(p(x)) = d(e,p') 

iia(p(x)) = c(v,p') 


(e,p',o,c x (p(x),n)) 
(v,p',a,K) 


(Ceoei),p, a, k) 


(e ,p,a[a M> d(ei,/))],ca(o, «)) 
where a £ dom(a) 


(v,p,a,d(a,n)) 


(v,p,cr[ai-*c(y,p)],K) 


((Ax.e),p, a, c 2 (a, «)) 


(e, p[x h-> a], a, k) 



Figure 8. The LK machine. 



? i — ^r^t ?', where k G cr(a), b = alloc(^, k),u — tick(i, k) 


(x,p,a,a,t) 


(e, p', a U [b >-> c\(p(x), a)], b, u) 


ifaOO)) 3d(e,p') 




(x,p,a,a,t) 


(v,p',a,a,u) 


if o(p(x)) B c(v,p') 




{(e ei),p, a,a,t) 


(e ,p,a',b,u) 




where c = alloc(i, k), 




a = a U [c i— > d(ei , p) , b h-s- c 2 (c, a)] 


(v,p,a,a,t) 


(v, p , a U [a' H> c(v, p)], c, u) 


if k — Ci (a , c) 




((Xx.e),p,a,a,t) 


(e,p'\x >->• a'], &, c,u) 


if k = c 2 (a' , c) 





Figure 9. The abstract LK* machine. 



application expression, which forces the operator expression to a 
value. The address a is the address of the argument. 

The concrete state-space is defined as follows and the transition 
relation is defined in Figure[8] 

<; G E = Exp x Env x Store x Kont 

s G Storable ::= d(e,p) | c(v,p) 

n £ Kont ::= mt | c±(a, k) \ C2(a,n) 

When the control component is a variable, the machine looks up 
its stored value, which is either computed or delayed. If delayed, 
a Ci continuation is pushed and the frozen expression is put in 
control. If computed, the value is simply returned. When a value 
is returned to a ci continuation, the store is updated to reflect the 
computed value. When a value is returned to a C2 continuation, its 
body is put in control and the formal parameter is bound to the 
address of the argument. 

We now refactor the machine to use store-allocated continua- 
tions: storable values are extended to include continuations: 



s £ Storable 
k £ Kont 



Exp x Env x Store x Addr 
d(e,p) j c(v,p) | k 
mt | ci(a, a) \ c^(a, a). 



It is straightforward to perform a pointer-refinement of the LK ma- 
chine to store-allocate continuations as done for the CESK machine 
in Section [2~3l and observe the lazy variant of Krivine's machine and 
its pointer-refined counterpart (not shown) operate in lock-step: 

Lemma 4. evalhK(e) ~ evalhK* (e). 

After threading time-stamps through the machine as done in 
Section [2741 and defining tick and alloc analogously to the defi- 



nitions given in Section [275] the pointer- refined machine abstracts 
directly to yield the abstract LK* machine in Figure [9] 

The abstraction map for this machine is a straightforward struc- 
tural abstraction similar to that given in Section 12,61 (and hence 
omitted). The abstracted machine is sound with respect to the LK* 
machine, and therefore the original LK machine. 

Theorem 3 (Soundness of the Abstract LK* Machine). 

If \ i — >lk C and a(c) C <j, then there exists an abstract state <;', 

such that ? i — ^r^f C and q(<; ) Cf , 

Optimizing the machine through specialization: Ager et al. opti- 
mize the LK machine by specializing application transitions. When 
the operand of an application is a variable, no delayed computa- 
tion needs to be constructed, thus "avoiding the construction of 
space-leaky chains of thunks." Likewise, when the operand is a 
A-abstraction, "we can store the corresponding closure as a com- 
puted value rather than as a delayed computation." Both of these 
optimizations, which conserve valuable abstract resources, can be 
added with no trouble, as shown in Figure [Tol 

? i — >r£n <?', where k £ <r(a), b — alloc(s, k), u — tick(q, k) 



■j i — >f-jyn; £'> where k £ a(a),b = alloc(<;, k),U — tick(<;, k) 



((ex),p,a,a,t) 


{e,p,a U[()H c 2 (p(x),a)],&, u) 


((ev),p,a,a,t) 


(e , p, a U [6h4 c(«,p),cH> c 2 (b, a)] , c, u) 




where c = alloc(s, k) 



Figure 10. The abstract optimized LK* machine. 

Varying the machine through postponed thunk creation: Ager 
et al. also vary the LK machine by postponing the construction of a 
delayed computation from the point at which an application is the 
control string to the point at which the operator has been evaluated 
and is being applied. The c 2 continuation is modified to hold, rather 
than the address of a delayed computation, the constituents of the 
computation itself: 

k £ Kont ::= mt | c±(a,a) | c 2 (e,p, a). 

The transitions for applications and functions are replaced with 
those in FigurefTTI This allocates thunks when a function is applied, 
rather than when the control string is an application. 

As Ager et al. remark, each of these variants gives rise to an 
abstract machine. From each of these machines, we are able to 
systematically derive their abstractions. 

4. State and control 

We have shown that store-allocated continuations make abstract 
interpretation of the CESK machine and a lazy variant of Krivine's 
machine straightforward. In this section, we want to show that 
the tight correspondence between concrete and abstract persists 
after the addition of language features such as conditionals, side 
effects, exceptions and continuations. We tackle each feature, and 
present the additional machinery required to handle each one. In 
most cases, the path from a canonical concrete machine to pointer- 
refined abstraction of the machine is so simple we only show the 
abstracted system. In doing so, we are arguing that this abstract 
machine-oriented approach to abstract interpretation represents a 
flexible and viable framework for building abstract interpreters. 

4.1 Conditionals, mutation, and control 

To handle conditionals, we extend the language with a new syn- 
tactic form, (if e e e), and introduce a base value #f, rep- 
resenting false. Conditional expressions induce a new continua- 
tion form: if(eo, ei, p, a), which represents the evaluation context 
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Figure 11. The abstract thunk postponing LK* machine. 



r^r* ?', where k £ a(a),b = alloc(s, k), u — tick(£, ft) 



((if e ei e 2 ),p,a,a,t) 


(e ,p, <rU [b M> if(ei,e 2 ,p, a)],b, u) 


{#f,p,a,a,t) 


{ei,p',a,c,u} 


\fn — if(e ,ei,p',c) 




(v,p,a,a,t) 


{e Q ,p',a,c,u) 


if k = if(e ,ei, p',c), 




and v 7^ #f 




((set! x e) , p, a, a, t) 


(e, p, a U [b n> set(p(x),a)], b, u) 


(v,p,a,a,t) 


{v' , p,a U [a' i-» v],c, u) 


if k = set (a , c) 


where v £ a(a') 


{ (A#.e) , p, a, a, t) 


{e, p[x t-¥ b] , a U [b h-> c],c,u) 


if k — fn(callcc, p , c) 


where c = alloc(s, k) 


(c,p,a,a,t) 


(a,p,a,c,u) 


if k — fn(callcc, p ,a ) 




(v,p,a,a,t) 


(v,p,a,c,u) 


if k — fn(c, p' ,a) 





Figure 12. The abstract extended CESK* machine. 

-B[(if [ ] eo ei)] where p closes e' to represent eo, p closes ei to 
represent ei, and a is the address of the representation of E. 

Side effects are fully amenable to our approach; we introduce 
Scheme's set ! for mutating variables using the (set! x e) syntax. 
The set ! form evaluates its subexpression e and assigns the value 
to the variable x. Although set ! expressions are evaluated for 
effect, we follow Felleisen et al. and specify set ! expressions 
evaluate to the value of x before it was mutated 1 1 1 page 166]. The 
evaluation context _E[(set! x [ ])] is represented by set(ao,ai), 
where ao is the address of x's value and a\ is the address of the 
representation of E. 

First-class control is introduced by adding a new base value 
callcc which reifies the continuation as a new kind of applicable 
value. Denoted values are extended to include representations of 
continuations. Since continuations are store-allocated, we choose to 
represent them by address. When an address is applied, it represents 
the application of a continuation (reified via callcc) to a value. 
The continuation at that point is discarded and the applied address 
is installed as the continuation. 

The resulting grammar is: 



e £ Exp 
k £ Kont 
v £ Val 



(if e e e) | (set! x e) 
if(e,e, p, a) \ set(a,a) 
#f I callcc I a. 



We show only the abstract transitions, which result from store- 
allocating continuations, time-stamping, and abstracting the con- 
crete transitions for conditionals, mutation, and control. The first 
three machine transitions deal with conditionals; here we follow 
the Scheme tradition of considering all non-false values as true. 
The fourth and fifth transitions deal with mutation. 



? I >CESHK C 



(v, p, a, hn(«', p', k, rj), mt) (v, p, a, rj, k) 

((throw v) , p,a, hn((As.e) , p 1 , k! ,rj), n) 

{e,p'[x i4o],(r[(irt (v,p)],tj,k'} 
where a £ dom(a) 

((catch e V s ) , p,o,rj,n) (e, p, a, hn(«, p, k, rj), mt) 

Figure 13. The CESHK machine. 



c* c', where rj — cr(h), K — o(a), b £ dom(a) 



(v,p,cr,h,a) 

if rj = hn(i/, p , a , ft'), 

and k — mt 


(v,p,o;h',a') 


( (throw v) , p,o, ft, a) 

if rj = hn((Aa;.e) , p', o', ft.') 


(e, p'[a; h-> 6], <t[6 h^ ( Vj p)], ft', a') 


((catch e v) , p, a, ft, a) 


(e, p, a[b M- hn(i>, p, a, ft)], 6, a mt ) 



Figure 14. The CESHK* machine. 



The remaining three transitions deal with first-class control. In 
the first of these, callcc is being applied to a closure value v. 
The value v is then "called with the current continuation", i.e., v 
is applied to a value that represents the continuation at this point. 
In the second, callcc is being applied to a continuation (address). 
When this value is applied to the reified continuation, it aborts the 
current computation, installs itself as the current continuation, and 
puts the reified continuation "in the hole". Finally, in the third, 
a continuation is being applied; c gets thrown away, and v gets 
plugged into the continuation b. 

In all cases, these transitions result from pointer-refinement, 
time-stamping, and abstraction of the usual machine transitions. 

4.2 Exceptions and handlers 

To analyze exceptional control flow, we extend the CESK machine 
with a register to hold a stack of exception handlers. This models 
a reduction semantics in which we have two additional kinds of 
evaluation contexts: 



E 
F 
H 



(catch E v) 



| (Ee) | (vE) 
| (Fe) | (vF) 
] J H[F[(ca.tch H v)]], 

and the additional, context-sensitive, notions of reduction: 



(catch £'[(throw v)] v ) — > (v v), (catch v V ) — ¥ V. 

H contexts represent a stack of exception handlers, while F con- 
texts represent a "local" continuation, i.e., the rest of the compu- 
tation (with respect to the hole) up to an enclosing handler, if any. 
E contexts represent the entire rest of the computation, including 
handlers. 

The language is extended with expressions for raising and 
catching exceptions. A new kind of continuation is introduced to 
represent a stack of handlers. In each frame of the stack, there is a 
procedure for handling an exception and a (handler-free) continua- 
tion: 

e G Exp ::— ... \ (throw v) | (catch e (Az.e)) 
rj € Handl ::— mt | hn(u, p,n,rf) 

An rj continuation represents a stack of exception handler contexts, 
i.e., hn(v' , p,K,rj) represents H[_F[(catch [ ] v)]], where rj 
represents H, k represents F, and p closes v' to represent v. 

The machine includes all of the transitions of the CESK ma- 
chine extended with a rj component; these transitions are omitted 
for brevity. The additional transitions are given in Figure [T3] This 
presentation is based on a textbook treatment of exceptions and 
handlers 1111 page 135]|jThe initial configuration is given by: 

m 3cESHK(e) = (e,0,0,mt,mt). 



* CESHk* *>'' wnere V e °{h)> K £ °"( a )i b — alloc(s, rj, k) 
u — ticfc(c, rj, k) 



5 To be precise, Felleisen et al. present the CHC machine, a substitution 
based machine that uses evaluation contexts in place of continuations. 
Deriving the CESHK machine from it is an easy exercise. 



(v, p,a,h,a,t) {v, p,&, ft ,a ,u) 

if rj — hn(u' , p' , a' , ft'), 

and k — mt 

( (throw v) , p,a,h,a,t) 

if rj — hn((Aa:.e), p', a' , ft') 

(e, p'\x i— >■ 6] , a U [6 i— > (v, p)], ft', a! , u) 
((catch e v) , p, a, ft, a, t) | 

(e, p, a U [b >-¥ hn(v, p, a, ft)], b, a mt ,u) 

Figure 15. The abstract CESHK* machine. 



In the pointer-refined machine, the grammar of handler contin- 
uations changes to the following: 

rj G Handl ::= mt | hn(u, p, a, ft), 

where ft is used to range over addresses pointing to handler con- 
tinuations. The notation a m t means a such that a (a) — mt in 
concrete case and mt g a (a) in the abstract, where the intended 
store should be clear from context. The pointer-refined machine is 
given in Figure [141 

After threading time-stamps through the machine as done in 
Section l2l4l the machine abstracts as usual to obtain the machine 
in Figure Q3] The only unusual step in the derivation is to observe 
that some machine transitions rely on a choice of two continuations 
from the store; a handler and a local continuation. Analogously 
to Section [231 we extend tick and alloc to take two continuation 
arguments to encode the choice: 

tick : E x Handl x Kont — ► Time, 

alloc : E x Handl x Kont -¥ Addr. 



5. Abstract garbage collection 

Garbage collection determines when a store location has become 
unreachable and can be re-allocated. This is significant in the ab- 
stract semantics because an address may be allocated to multiple 
values due to finiteness of the address space. Without garbage col- 
lection, the values allocated to this common address must be joined, 
introducing imprecision in the analysis (and inducing further, per- 
haps spurious, computation). By incorporating garbage collection 
in the abstract semantics, the location may be proved to be un- 
reachable and safely overwritten rather than joined, in which case 
no imprecision is introduced. 

Like the rest of the features addressed in this paper, we can 
incorporate abstract garbage collection into our static analyzers 
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(e,p,a,a) 



(e,p,{(b,<T(b))\b£L},a) 



if {££„(e,p)U ££„(a(a)),{a},a) t-^oc (0,C,cr) 



Figure 16. The GC transition for the CESK* machine. 



by a straightforward pointer-refinement of textbook accounts of 
concrete garbage collection, followed by a finite store abstraction. 
Concrete garbage collection is defined in terms of a GC machine 
that computes the reachable addresses in a store 1 1 1 page 172]: 

{G, B, a) ^ GC ((G U ££ CT (a(a)) \ (B U {a})), B U {a}, a) 
if a eG. 

This machine iterates over a set of reachable but unvisited "grey" 
locations g. On each iteration, an element is removed and added 
to the set of reachable and visited "black" locations B. Any newly 
reachable and unvisited locations, as determined by the "live loca- 
tions" function ££ a , are added to the grey set. When there are no 
grey locations, the black set contains all reachable locations. Ev- 
erything else is garbage. 

The live locations function computes a set of locations which 
may be used in the store. Its definition will vary based on the partic- 
ular machine being garbage collected, but the definition appropriate 
for the CESK* machine of Section[2~3lis 



££ CT (e) = 
££ CT (e,p) - ££ CT (p|fv(e)) 

££ a {p) = rng(p) 
££ CT (mt) = 
££ CT (fn(w,p, a)) — {a} U££ CT (v, p) U££ CT (cr(a)) 
££ CT (ar(e,p, a)) = {a} U££ CT (e,p) U ££ CT (er(a)). 

We write p|fv(e) to mean p restricted to the domain of free vari- 
ables in e. We assume the least-fixed-point solution in the calcula- 
tion of the function ££ in cases where it recurs on itself. 

The pointer-refinement of the machine requires parameterizing 
the ££ function with a store used to resolve pointers to continua- 
tions. A nice consequence of this parameterization is that we can 
re-use ££ for abstract garbage collection by supplying it an ab- 
stract store for the parameter. Doing so only necessitates extending 
££ to the case of sets of storable values: 



££ a {S)= lj££ CT ( S ) 



The CESK* machine incorporates garbage collection by a tran- 
sition rule that invokes the GC machine as a subroutine to remove 
garbage from the store (Figure [16). The garbage collection transi- 
tion introduces non-determinism to the CESK* machine because 
it applies to any machine state and thus overlaps with the existing 
transition rules. The non-determinism is interpreted as leaving the 
choice of when to collect garbage up to the machine. 

The abstract CESK* incorporates garbage collection by the 
concrete garbage collection transition, i.e., we re-use the definition 
in Figure [T6] with an abstract store, o, in place of the concrete 
one. Consequently, it is easy to verify abstract garbage collection 
approximates its concrete counterpart. 

The CESK* machine may collect garbage at any point in the 
computation, thus an abstract interpretation must soundly approx- 
imate all possible choices of when to trigger a collection, which 
the abstract CESK* machine does correctly. This may be a useful 
analysis of garbage collection, however it fails to be a useful anal- 
ysis with garbage collection: for soundness, the abstracted machine 



must consider the case in which garbage is never collected, imply- 
ing no storage is reclaimed to improve precision. 

However, we can leverage abstract garbage collection to reduce 
the state-space explored during analysis and to improve precision 
and analysis time. This is achieved (again) by considering proper- 
ties of the concrete machine, which abstract directly; in this case, 
we want the concrete machine to deterministically collect garbage. 
Determinism of the CESK* machine is restored by defining the 
transition relation as a non-GC transition (Figure[3} followed by the 
GC transition (FigurefTBTl. This state-space of this concrete machine 
is "garbage free" and consequently the state-space of the abstracted 
machine is "abstract garbage free." 

In the concrete semantics, a nice consequence of this property is 
that although continuations are allocated in the store, they are deal- 
located as soon as they become unreachable, which corresponds to 
when they would be popped from the stack in a non-pointer-refined 
machine. Thus the concrete machine really manages continuations 
like a stack. 

Similarly, in the abstract semantics, continuations are deallo- 
cated as soon as they become unreachable, which often corresponds 
to when they would be popped. We say often, because due to the 
finiteness of the store, this correspondence cannot always hold. 
However, this approach gives a good finite approximation to in- 
finitary stack analyses that can always match calls and returns. 

6. Abstract stack inspection 

In this section, we derive an abstract interpreter for the static analy- 
sis of a higher-order language with stack inspection. Following the 
outline of Sectionf2]and[3] we start from the tail-recursive CM ma- 
chine of Clements and Felleisen |3|, perform a pointer refinement 
on continuations, then abstract the semantics by a parameterized 
bounding of the store. 

6.1 The A sec -calculus and stack-inspection 

The A scc -calculus of Pottier, Skalka, and Smith is a call-by-value 
A-calculus model of higher-order stack inspection [26|. We present 
the language as given by Clements and Felleisen (3). 

All code is statically annotated with a given set of permissions 
R, chosen from a fixed set P. A computation whose source code 
was statically annotated with a permission may enable that permis- 
sion for the dynamic extent of a subcomputation. The subcompu- 
tation is privileged so long as it is annotated with the same per- 
mission, and every intervening procedure call has likewise been 
annotated with the privilege. 

e £ Exp ::=... | fail | (grant R e) \ 

(test R e e) (frame R e) 

A fail expression signals an exception if evaluated; by convention 
it is used to signal a stack-inspection failure. A (frame R e) eval- 
uates e as the principal R, representing the permissions conferred 
on e given its origin. A (grant R e) expression evaluates as e but 
with the permissions extended with R enabled. A (test R eo ei) 
expression evaluates to eo if R is enabled and ei otherwise. 

A trusted annotator consumes a program and the set of permis- 
sions it will operate under and inserts frame expressions around 
each A-body and intersects all grant expressions with this set of per- 
missions. We assume all programs have been properly annotated. 

Stack inspection can be understood in terms of an OK predi- 
cate on an evaluation contexts and permissions. The predicate de- 
termines whether the given permissions are enabled for a subex- 
pression in the hole of the context. The OK predicate holds when- 
ever the context can be traversed from the hole outwards and, for 
each permission, find an enabling grant context without first finding 
a denying frame context. 
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(fail,p, a, mt ) 


{ (frame R e) , p, a, k) 
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Figure 17. The CM machine and OK predicate. 



6.2 The CM machine 

The CM (continuation-marks) machine of Clements and Felleisen 
is a properly tail-recursive extended CESK machine for interpreting 
higher-order languages with stack-inspection (3). 

In the CM machine, continuations are annotated with marks |4|, 
which, for the purposes of stack-inspection, are finite maps from 
permissions to {deny, grant}: 

K ::= mt m | ar m (e,/9,K) | fn m (u,p,«:). 

We write k[R h > c] to mean update the marks on k to m[R n> c]. 

The CM machine is defined in Figure [771 (transitions that are 
straightforward adaptations of the corresponding CESK* transi- 
tions to incorporate continuation marks are omitted). It relies on 
the OK predicate to determine whether the permissions in R are 
enabled. The OK predicate performs the traversal of the context 
(represented as a continuation) using marks to determine which 
permissions have been granted or denied. 

The semantics of a program is given by the set of reachable 
states from an initial machine configuration: 

in JcM( e ) = < e .0> [ fl o ^ mt ],a o ). 

6.3 The abstract CM* machine 

Store-allocating continuations, time-stamping, and bounding the 
store yields the transition system given in Figure [J_8] The notation 
a(a)[R i— > c] is used to mean [R i— >■ c] should update some 
continuation in a(a), i.e., 

a(a)[R M> c] = a[a H> a(a) \ {k} U {k[R H> c]}], 

for some k £ a(a). It is worth noting that continuation marks are 
updated, not joined, in the abstract transition system. 

The OK* predicate (Figure[T8l> approximates the pointer refine- 
ment of its concrete counterpart OK, which can be understood as 
tracing a path through the store corresponding to traversing the con- 
tinuation. The abstract predicate holds whenever there exists such a 
path in the abstract store that would satisfy the concrete predicate: 
Consequently, in analyzing (test R eo ei), eo is reachable only 
when the analysis can prove the OK* predicate holds on some path 
through the abstract store. 

It is straightforward to define a structural abstraction map and 
verify the abstract CM* machine is a sound approximation of its 
concrete counterpart: 

Theorem 4 (Soundness of the Abstract CM* Machine). 

If i, i — > cm ? and a (?) C <;, then there exists an abstract state £, , 

such that ? i— 



(fail,p,<r,a) 


(fail,/9, <r,a mt ) 


( (frame R e) , p, a, a) 


(e, p, <r(a) [R h-» deny] , a) 


{ (grant R e) , p, a, a) 


(e, p, a(a)[R i-» grant], a) 


((test R eo ei ) , p, a, a) 


\{eo,p,a,a) if OK*(R, a, a), 
1 (ei, p, o, a) otherwise. 



OK*($,o,a) 

OK*(R,a,a) 
ifo-(a) 9mt m 

OK*(R,a,a) 

ifa(a) Bfn m {v,p,b) 
or a(a) 9 ar m (e,p, b) 



(.Rnm-^deny) = 0) 

(i?nm _1 (deny) = 0) A 
(5a?0R\ migrant), <r, 6) 



tt ?' anda(<;') C ?', 



Figure 18. The abstract CM* machine. 

7. Widening to improve complexity 

If implemented naively, it takes time exponential in the size of the 
input program to compute the reachable states of the abstracted 
machines. Consider the size of the state-space for the abstract time- 
stamped CESK* machine: 

\Exp x Env x Store x Addr x Time| 

= \Exp\ x |,<Wdr| |Var| x \Storable\ lAddr] x \Addr\ x \Time\. 

Without simplifying any further, we clearly have an exponential 
number of abstract states. 

To reduce complexity, we can employ widening in the form of 
Shivers's single-threaded store [29]. To use a single threaded store, 
we have to reconsider the abstract evaluation function itself. Instead 
of seeing it as a function that returns the set of reachable states, it 
is a function that returns a set of partial states plus a single globally 
approximating store, i.e., aval : Exp — > System, where: 

System = V {Exp x Env x Addr x Time) x Store. 

We compute this as a fixed point of a monotonic function, /: 

/ : System — > System 

f(C,o) = (C',a") where 

Q — {(c ,&) : c € C and (c, a) i — > (c , o ) } 

(c ,<To) = inj{e) 

C' = C\j{c :(c',.)GQ'}u{c } 

a" = a U [J a', 
(-,*')eQ' 

so that aval(e) = lfp(/). The maximum number of iterations of 
the function / times the cost of each iteration bounds the complex- 
ity of the analysis. 

Polynomial complexity for monovariance: It is straightforward 
to compute the cost of a monovariant (in our framework, a "OCFA- 
like") analysis with this widening. In a monovariant analysis, envi- 
ronments disappear; a monovariant system-space simplifies to: 

System 

— V {Exp x Lab x Lab±) 

addresses fn conts ar conts 

x (( Var + Lab) — > (Exp x Lab) + (Exp x Lab) +Lam). 



If ascended monotonically, one could add one new partial state 
each time or introduce a new entry into the global store. Thus, the 
maximum number of monovariant iterations is: 

\Exp\ x \Lab\ 2 + 1 

+ | Var + Lab\ x (2\Exp x Lab\ + \Lam\), 

which is cubic in the size of the program. 

8. Related work 

The study of abstract machines for the A-calculus began with 
Landin's SECD machine 1211 . the theory of abstract interpreta- 
tion with the POPL papers of the Cousots' |6 7], and static analy- 
sis of the A-calculus with Jones's coupling of abstract machines 
and abstract interpretation 1 1 VII - All three have been active ar- 
eas of research since their inception, but only recently have well 
known abstract machines been connected with abstract interpreta- 
tion by Midtgaard and Jensen 1 23 . 24]. We strengthen the connec- 
tion by demonstrating a general technique for abstracting abstract 
machines. 

Abstract interpretation of abstract machines: The approxima- 
tion of abstract machine states for the analysis of higher-order lan- 
guages goes back to Jones [17], who argued abstractions of regular 
tree automata could solve the problem of recursive structure in en- 
vironments. We re-invoked that wisdom to eliminate the recursive 
structure of continuations by allocating them in the store. 

Midtgaard and Jensen present a OCFA for a CPS A-calculus lan- 
guage [23 ]. The approach is based on Cousot-style calculational ab- 
stract interpretation |5|, applied to a functional language. Like the 
present work, Midtgaard and Jensen start with an "off-the-shelf" 
abstract machine for the concrete semantics (in this case, the CE 
machine of Flanagan, et al. 1141 ) and employ a reachable-states 
model. They then compose well-known Galois connections to re- 
veal a OCFA with reachability in the style of Ayers |2||3 The CE 
machine is not sufficient to interpret direct-style programs, so the 
analysis is specialized to programs in continuation-passing style. 
Later work by Midtgaard and Jensen went on to present a similar 
calculational abstract interpretation treatment of a monomorphic 
CFA for an ANF A-calculus [24]. The concrete semantics are based 
on reachable states of the C a EK machine 1 14 1 . The abstract seman- 
tics approximate the control stack component of the machine by its 
top element, which is similar to the labeled machine abstraction 
given in Section l2~7l when k = 0. 

Although our approach is not calculational like Midtgaard and 
Jensen's, it continues in their tradition by applying abstract inter- 
pretation to off-the-shelf tail-recursive machines. We extend the 
application to direct-style machines for a fc-CFA-like abstraction 
that handles tail calls, laziness, state, exceptions, first-class contin- 
uations, and stack inspection. We have extended return flow anal- 
ysis to a completely direct style (no ANF or CPS needed) within a 
framework that accounts for polyvariance. 

Harrison gives an abstract interpretation for a higher-order lan- 
guage with control and state for the purposes of automatic paral- 
lelization 1151 . Harrison maps Scheme programs into an impera- 
tive intermediate language, which is interpreted on a novel abstract 
machine. The machine uses a procedure string approach similar to 
that given in Section |2~71 in that the store is addressed by proce- 
dure strings. Harrison's first machine employs higher-order values 
to represent functions and continuations and he notes, "the straight- 
forward abstraction of this semantics leads to abstract domains 



Ayers derived an abstract interpreter by transforming (the representation 
of) a denotational continuation semantics of Scheme into a state transition 
system (an abstract machine), which he then approximated using Galois 
connections |2|. 



containing higher-order objects (functions) over reflexive domains, 
whereas our purpose requires a more concrete compile-time repre- 
sentation of the values assumed by variables. We therefore modify 
the semantics such that its abstraction results in domains which are 
both finite and non-reflexive." Because of the reflexivity of deno- 
table values, a direct abstraction is not possible, so he performs 
closure conversion on the (representation of) the semantic func- 
tion. Harrison then abstracts the machine by bounding the proce- 
dure string space (and hence the store) via an abstraction he calls 
stack configurations, which is represented by a finite set of mem- 
bers, each of which describes an infinite set of procedure strings. 

To prove that Harrison's abstract interpreter is correct he argues 
that the machine interpreting the translation of a program in the 
intermediate language corresponds to interpreting the program as 
written in the standard semantics — in this case, the denotational 
semantics of R 3 RS. On the other hand, our approach relies on well 
known machines with well known relations to calculi, reduction 
semantics, and other machines |10| [8l. These connections, coupled 
with the strong similarities between our concrete and abstract ma- 
chines, result in minimal proof obligations in comparison. More- 
over, programs are analyzed in direct-style under our approach. 

Abstract interpretation of lazy languages: Jones has analyzed 
non-strict functional languages 1 17, 16], but that work has only fo- 
cused on the by-name aspect of laziness and does not address mem- 
oization as done here. Sestoft examines flow analysis for lazy lan- 
guages and uses abstract machines to prove soundness 1 27 1 . In par- 
ticular, Sestoft presents a lazy variant of Krivine's machine similar 
to that given in Section[3]and proves analysis is sound with respect 
to the machine. Likewise, Sestoft uses Landin's SECD machine as 
the operational basis for proving globalization optimizations cor- 
rect. Sestoft's work differs from ours in that analysis is developed 
separately from the abstract machines, whereas we derive abstract 
interpreters directly from machine definitions. Faxen uses a type- 
based flow analysis approach to analyzing a functional language 
with explicit thunks and evals, which is intended as the intermedi- 
ate language for a compiler of a lazy language |9|. In contrast, our 
approach makes no assumptions about the typing discipline and an- 
alyzes source code directly. 

Realistic language features and garbage collection: Static an- 
alyzers typically hemorrhage precision in the presence of excep- 
tions and first-class continuations: they jump to the top of the lattice 
of approximation when these features are encountered. Conversion 
to continuation- and exception-passing style can handle these fea- 
tures without forcing a dramatic ascent of the lattice of approxima- 
tion |29|. The cost of this conversion, however, is lost knowledge — 
both approaches obscure static knowledge of stack structure, by 
desugaring it into syntax. 

Might and Shivers introduced the idea of using abstract garbage 
collection to improve precision and efficiency in flow analysis 1251 . 
They develop a garbage collecting abstract machine for a CPS lan- 
guage and prove it correct. We extend abstract garbage collection 
to direct-style languages interpreted on the CESK machine. 

Static stack inspection: Most work on the static verification of 
stack inspection has focused on type-based approaches. Skalka 
and Smith present a type system for static enforcement of stack- 
inspection 1 30 1 . Pottier et al. present type systems for enforcing 
stack-inspection developed via a static correspondence to the dy- 
namic notion of security-passing style |26|. Skalka et al. present 
type and effect systems that use linear temporal logic to express 
regular properties of program traces and show how to statically en- 
force both stack- and history-based security mechanisms |31 ]. Our 
approach, in contrast, is not typed-based and focuses only on stack- 
inspection, although it seems plausible the approach of Section [6] 
extends to the more general history-based mechanisms. 



9. Conclusions and perspective 

We have demonstrated the utility of store-allocated continuations 
by deriving novel abstract interpretations of the CEK, a lazy vari- 
ant of Krivine's, and the stack-inspecting CM machines. These 
abstract interpreters are obtained by a straightforward pointer re- 
finement and structural abstraction that bounds the address space, 
making the abstract semantics safe and computable. Our technique 
allows concrete implementation technology to be mapped straight- 
forwardly into that of static analysis, which we demonstrated by in- 
corporating abstract garbage collection and optimizations to avoid 
abstract space leaks, both of which are based on existing accounts 
of concrete GC and space efficiency. Moreover, the abstract inter- 
preters properly model tail-calls by virtue of their concrete coun- 
terparts being properly tail-call optimizing. Finally, our technique 
uniformly scales up to richer language features. We have supported 
this by extending the abstract CESK machine to analyze condition- 
als, first-class control, exception handling, and state. We speculate 
that store-allocating bindings and continuations is sufficient for a 
straightforward abstraction of most existing machines. 
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